Method for accessing data of an automation apparatus and corresponding automation apparatus

ABSTRACT

The invention relates to a method for accessing data of an automation apparatus and an automation apparatus suitable for the embodiment thereof, wherein access to data on a remote terminal is carried out by means of a remote terminal in accordance with a standard protocol, wherein the automaton apparatus has a client and/or server for handling communication tasks in accordance with the standard protocol and a converter for converting a communication task into a format that can be processed by a functional interface into an internal functionality of the automation apparatus for direct access to the data thereof.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is the US National Stage of International ApplicationNo. PCT/DE02/04116, filed Nov. 6, 2002 and claims the benefit thereof.The International Application claims the benefits of German applicationNo. 10157251.4 filed Nov. 22, 2001, both of the applications areincorporated by reference herein in their entirety.

FIELD OF INVENTION

The invention relates to a method for accessing data of an automationdevice. The invention also relates to an automation device which issuitable for executing the method.

BACKGROUND OF INVENTION

Automation devices are used for controlling and/or monitoring technicalprocesses. Special automation devices are known as so-called storedprogrammable controls. Other special automation devices are formed by aso-called process computer. Automation devices only differ fromso-called standard computers, like those used today for officeapplications, by virtue of extended connection possibilities, a reducedspecific functionality, and the suitability for use in industrialenvironments. The extended connection possibilities result from the needto connect the process peripheral equipment to the automation device, inorder to receive data from the process which is being controlled and/ormonitored and in order to output control information to the process. Foruse in normal industrial environments, a special casing or a suitableshielding is provided in order to protect against damage by mechanicalor chemical effects or against electromagnetic interference effects. Thefunctionality is essentially reduced to controlling and monitoringfunctions and the associated necessary processing functions.

These known automation devices have a memory, in which an object modelis stored, and a functional interface which is also stored in the memoryand allows an access to the object model. The automation devices ofSiemens AG having the designation SIMATIC S7-300 or SIMATIC S7-400 arecited by way of example.

On the one hand, the object model of the automation device describes theorganization of the data stored in the automation device, but on theother hand it also includes the stored data itself, namely e.g.so-called organization modules, abbreviated to OB, so-called datamodules, abbreviated to DB, so-called function modules, abbreviated toFB, so-called function calls, abbreviated to FC, and so-called systemfunction calls, abbreviated to SFC, to name but a few. These can beaccessed by means of the function interface, using functions which aredefined for the automation device. The totality of the operation modulesand function modules forms the actual control program. In addition, theobject model includes so-called data modules, in which data is storedfor internal linking or for storing intermediate results. The objectmodel also includes a further input storage area and output storagearea, in which are stored the data which is received from the processand the data for outputting to the process respectively.

EP-A-0 540 903 discloses an automation device having a networkinterface. The user program, inter alia, can be loaded into the controlmodule via this interface.

WO-A-91 14988 discloses an automation device having a bus-compatibleinterface. However, this interface is not used as a program interface.

Each of the known automation devices has the disadvantage that, due tothe restricted functionality of the automation device, an exchange ofdata between an automation device and a “standard computer” is onlypossible under certain conditions because, in addition to so-calledinputs and outputs for connecting the process peripheral equipment, onlyone interface is provided for connecting a programming device, which isalso proprietary, by means of a communication protocol which is definedfor this purpose.

SUMMARY OF INVENTION

The present invention addresses the problem of specifying a method whichallows the data of an automation device to be called up or modified bythe additional means of a standard computer.

In accordance with the invention, this problem is solved using a methodfor accessing data of an automation device as claimed in claim 1. Inthis case, the automation device has a memory and a function interfaceas disclosed in the prior art. The function interface is itself storedin the memory of the automation device and allows an access to theobject model which is stored in the memory of the automation device. Theobject model includes at least the control program which is executed onthe automation device or by the automation device and the data which isrequired for executing the control program, e.g. data received from atechnical process which is controlled by the control program, and datawhich is used for controlling the technical process.

In accordance with the invention, provision is made for the object modelof the automation device to be accessible via a communicationconnection, for which a standard protocol can be used. To this end, acommunication request which relates to the object model is forwardedfrom a client or a server to a converter, which converts thecommunication request into a format which can be processed by thefunction interface.

A so-called FTP (FTP=File Transfer Protocol) or NFS (NFS=Network FileSystem) connection is cited here as a connection having a standardprotocol. The File Transfer Protocol is based on a so-calledclient-server architecture. When this protocol is used, data isexchanged between a so-called FTP server and a so-called FTP clientaccordingly. The data is stored on an FTP server; the data transmissioninvolves one or more FTP clients which access the server. FTP allows adata transfer both from the client to the server and from the server tothe client. A standard FTP server therefore offers the minimumfunctionality of being able to display the content of its data resourcesto an FTP client (directory), being able to transmit data to an FTPclient (get/read), or being able to receive data from an FTP client(put/write). A standard FTP client correspondingly offers the minimumfunctionality of being able to call up a display of the content of thedata resources of an FTP server (directory), being able to receive datafrom an FTP server (get/read) or being able to transmit data to an FTPserver (put/write).

In order to make the data additionally available outside of the relevantautomation device, or available to devices which are designed in anycase for exchanging data with the relevant automation device, a clientor a server for handling the selected standard protocol is used inconjunction with the converter which converts accesses e.g. via an FTPserver into accesses to the automation device.

If a device which is designed in any case for exchanging data with therelevant automation device, e.g. a so-called programming device, is toread a data module from the automation device, e.g. the data module withthe number 1 which is abbreviated to DB 1 below, the function whichtransfers the data module to the programming device is selectedaccordingly. For this purpose, the automation device includes acorresponding collection of functions in its function interface, saidfunctions allowing the different accesses, e.g. “read”, “write”, etc.,made by the programming device to the object model of the automationdevice.

IF a terminal which is not especially designed for exchanging data withthe relevant automation device, e.g. a so-called personal computer, isto read the same data module from the automation device, this must bedone using the functions of the standard protocol. Various applicationsfor use with the relevant terminal are available for handling thestandard protocol on the personal computer side. However, the automationdevice is not directly capable of interpreting the standard protocolwhich is selected in each case. Therefore the converter acts as anintermediary between client or server and the function interface.Communication requests in accordance with the standard protocol aretransformed by the converter into a format which can be processed by thefunction interface. If data is to be written to the object model of theautomation device, this is initially done using a write function(put/write) in accordance with the standard protocol, said writefunction being converted by the converter into a write function whichcan be handled by the function interface. If data is to be read from theobject model of the automation device, this is initially done using aread function (get/read) in accordance with the standard protocol, saidread function being converted by the converter into a read functionwhich can be handled by the function interface.

Appropriate developments of the method as claimed in Claim 1 are thesubject matter of the dependent claims which refer back to this claim.

In accordance with a configuration of the claimed method, the converteralso converts a communication request from the function interface into aformat which can be processed by the client or the server, and forwardsthe converted communication request to the client or the server. Theadvantage of such a configuration is that the automation device can alsofunction as an active communication partner in a communicationrelationship and, for example, can transfer relevant data when aspecific status is reached in the controlled process.

It is also advantageous for the client or server to be part of theautomation device and communicatively connected to a standard interfaceof the automation device. The communication requests which are receivedor sent via the standard interface are processed by the client or serverin accordance with the standard protocol. The advantage of such aconfiguration is that terminals from a wide variety of manufacturers andperformance classes can be connected to the automation device via thestandard interface, and data can be transferred between the automationdevice and each connectable terminal in this way.

If the converter presents the object model and its structure to theclient or server in a hierarchical format, access to the object model ofthe automation device can be particularly clear and user friendly.

In accordance with a further configuration of the invention, a structureof the object model is initially called up in order to access the dataof the automation device. The structure of the object model is an imageof the object model itself. It includes an image of the individualcomponents of the object model, e.g. the organization modules, datamodules, function modules, etc. As soon as the image of the object modelis available, a selection of the components contained therein ispossible. Individual components or a plurality of components areselected accordingly, with reference to the image of the structure ofthe object model. These components are then accessed, in that data inthe memory of the automation device is read or written via the functioninterface, said data corresponding to the selected components. It istherefore possible to access the object model in the same way as thedata on a fixed disk, for example, can be accessed using so-called filemanagers as found today in popular operating systems. On the basis ofrelevant training with such file managers, the user knows directly whichmeasures to apply in order to call up data from the object model of theautomation device, for example.

It is also advantageous for similar components in the object model to becombined in groups and transferable in groups. This again significantlyfacilitates access to the object model in that, e.g. when transferringall data modules, the complete group of all data modules can be selectedinstead of selecting each data module individually. The combining ofcomponents into groups continues along the hierarchy within thestructure of the object model in such a way that there is also one groupwhich contains all groups having a specific type of module in each case.The grouping at the highest hierarchical level ultimately corresponds tothe object model itself, such that a single selection allows all thedata resources of the automation device to be selected for the transfer.

It is advantageous for the structure of the object model to berepresented as a so-called tree with a so-called root, having at leastone so-called branch and at least one so-called leaf. The rootcorresponds to the grouping at the highest hierarchical level asdescribed above. Each leaf corresponds to a component of the objectmodel, e.g. a data module or function module, and each branchcorresponds to a grouped combination of similar components or otherbranches.

The object model is itself organized into a certain structure which isat least implicit, specifically into a form which comprises a set oforganization modules, a set of data modules, a set of function modules,etc. Each type of module is organizationally combined into a singlebranch, subsequently called a “directory”, wherein the directory itselfbears the name of the class of the data it contains or of theorganization form, e.g. “Function modules”. If a user switches to thedirectory called “Function modules”, an appropriate communicationrequest supplies a list of the function modules which are present on theautomation device to the user on the terminal side, in accordance withthe standard protocol. The user is then presented with the list offunction modules, e.g. “FB1, FB2, . . . FB7” and can select e.g. thefunction module with the number 7 (FB7) from this list for the transfer.This read operation is initiated by the client. As a result of thecommunication of the client with the server which is connected in frontof the automation device, therefore, the user of the terminal on which acorresponding client is present receives the data of the requestedfunction module on his or her terminal, e.g. his or her personalcomputer, as a transmitted file.

The nested structure described above can also include even deeperlevels, where a description of the data, and optionally a description ofthe program code or at least a representation of the program code whichcan be read more easily by users, is assigned or generated in additionto the actual data. To this end, provision is made for the image of thestructure of the object model to include further directories, which assubdirectories themselves describe the complete data structure of theautomation device in each case, but which are assigned different datadepending on the path within the directory. An example is a directoryhaving the name “Binary” and a directory having the name “Description”,where each of these directories contains subdirectories for theorganization modules, the data modules, the function modules, etc. Inorder to call up data from the object model, the user switches to thedirectory called “Binary” first, for example, and from there into thedirectory called “Organization modules”. If the organization modulehaving the number 7 is then selected, the corresponding organizationmodule is returned in a binary format. By comparison, if the user movesfrom the directory called “Description” into the directory called“Organization modules” and again selects the organization module havingthe number 7 from there, the corresponding organization module isreturned in a special text format, which facilitates the readability ofthe data contained in the organization module. For this purpose, whenthe collection of the data module from the automation device isinitiated, an interpretation of the data supplied by the automationdevice must be performed in addition to a transfer of the data. For anorganization module, this transfer functionality can be provided by aso-called disassembler, for example. Alternatively or additionally,provision can be made for holding an organization module in the memoryof the automation device both in binary format and in the format inwhich it can optionally be presented to the user. This is ultimately aquestion of the memory space available on the automation device. Similarconsiderations apply to plain text designations for so-called variableswhich are used in the control program, e.g. “DBl.7=Motor at creepvelocity”. This information “Motor at creep velocity” is not usuallycontained in the data module, but in a separate file called the signallist. In this case, when a specific data module is called up andprepared for transfer via the path “Description” “Data module”,provision is made in advance of the transfer for preparing not just thedata module itself for the transfer, but also those entries in thesignal list which relate to data of this data module, said entries beingadded to the transfer data in a suitable format, so that the user canread not just the data module with its layout, but also the plain textdesignation of the individual variables within the data module.

As an alternative to a comparatively deep nested directory structure, itis possible to have only directories for organization modules, datamodules, function modules, etc. as subdirectories of the so-called rootdirectory, and to identify the individual organization modules or datamodules as “files” in these subdirectories by means of differentso-called extensions according to their content, e.g. an extension of“binary” for binary content only and an extension of “description” forthe expanded content with plain text designations as described above.

It is also effective, starting from the root directory, to createdirectories which designate in plain text the automation devices whichbelong to an automation system. This can result in subdirectories havingthe designation “S7-300” and a further directory having the designation“S7-400” if these devices are present in the automation system. If aplurality of automation devices of the same performance class are resentin an automation system, ambiguities arise when naming the directoriesbranching from the root directory. This ambiguity is avoided if a uniquenumber is added to the designation, so that designations such as “S7-300[1]”, “S7-300 [2]”, etc. are generated. Alternatively, the device classdesignation is no longer selected as a directory name, and theautomation devices are instead designated using the names they weregiven during design, e.g. “Press control”, etc., or (again withreference to design data) using the geographic positions of theindividual automation devices, e.g. “Rack 7 slot 3”, or using a suitablelocation identifier.

In accordance with a relevant transfer operation, it is also possible onthe automation device side or on the terminal side to convert the dataof the automation device, said data being identified either as adirectory level or by an extension, into a machine-readable format, e.g.XML, which can then be interpreted on the terminal side and canoptionally be imported via an additional filter, for example, into astandard program, e.g. a spreadsheet program, a database program, avisualization program, etc.

The invention also addresses the problem of specifying a suitableautomation device for executing the method. This problem is solved by anautomation device in accordance with Claim 8. The dependent claimsrelate to preferred embodiments of the invention.

In accordance with the invention, an automation device having a memoryand a function interface, wherein the function interface itself is heldin the memory and is provided for accessing an object model which isstored in the memory, features a converter and a client and/or a server.The client or server forwards a communication request, which relates tothe object model and is therefore used for write or read access to theobject model, to the converter. The converter is used for converting thecommunication request into a format which can be processed by thefunction interface, and for forwarding the converted communicationrequest to the function interface.

If e.g. a communication request for reading the data module having thenumber 1 is initiated, this request arrives at the client or server,which is specially configured in this case and is connected in front ofthe automation device. The client or server recognizes that this is aread request which relates to data in the automation device, the objectmodel. The client or server passes the request to the converter, whichknows both the functionality of the client or server and thefunctionality of the function interface. The converter converts the readrequest into a corresponding call for reading data from the object modeland converts the parameter of the read request, e.g. “DB 1” in thiscase, into a corresponding parameter for selecting the first data modulein the memory of the automation device. A function call is finallygenerated therefore, which can be transferred to the automation deviceat its function interface. The generated function call corresponds to afunction call such as that which can be generated directly by aproprietary programming device. In response to the function call, theautomation device or more precisely its function interface returns thefirst data module. This data module or its data is transferred to theclient or server, which in turn transmits it onward to the counterpartof the client or server on the terminal side, and therefore the datafinally arrives at the terminal from which the data module wasrequested.

It is advantageous if the automation device has both a client and aserver and is therefore capable of functioning as both a data source anda data destination in a communication relationship with othercommunication participants, e.g. other automation devices or terminals.

It is additionally advantageous if the automation device has a standardinterface via which the client or server is communicatively connected.The client or server is thus suitable for handling incoming or outgoingcommunication requests via the standard interface in accordance with astandard protocol, e.g. FTP or NFS. A so-called personal computer, forexample, can be connected to the standard interface as a terminal. Ifthe automation device includes a server, the terminal which is used toaccess the automation device has a corresponding client. Conversely, ifthe automation device has a client, the terminal has a correspondingserver.

It is additionally advantageous if the converter also provides forconverting a communication request from the function interface into aformat which can be processed by the client or the server, and forforwarding the converted communication request to the client or theserver. The automation device can then also function as an activecommunication partner in a communication relationship and, e.g. sendrelevant data to the terminal when a specific status is reached in thecontrolled process. An example is production data which is logged by theautomation device during manufacture of a batch and is to be transferredto a supervisory station for the purpose of analysis after the end ofthe batch.

The client is advantageously an FTP client and the server an FTP serveraccordingly. This makes it possible to use the File Transfer Protocol(FTP), which is a widely used standard protocol, for accessing theobject model of the automation device.

Alternatively, the client is advantageously an NFS client and the serveran NFS server accordingly. This makes it possible to use the NFSprotocol (NFS=Network File System), which is likewise a widely usedstandard protocol, for accessing the object model of the automationdevice.

In accordance with a further alternative, the client is advantageouslyan NNTP client and the server an NNTP server accordingly. This makes itpossible to use the NNTP protocol (NNTP=Network News Transfer Protocol),which is likewise a widely used standard protocol, for accessing theobject model of the automation device.

BRIEF DESCRIPTION OF THE DRAWINGS

An exemplary embodiment of the invention is explained in greater detailbelow with reference to the drawings. Objects or elements whichcorrespond to each other are assigned the same reference signs in allthe figures, in which

FIG. 1 shows an automation device,

FIG. 2 shows an object model of an automation device,

FIG. 3 shows a structure of the object model, and

FIG. 4 shows a structure of a part of the object model, which part alsorelates to messages, e.g. status, warning or error messages.

DETAILED DESCRIPTION OF INVENTION

FIG. 1 shows an automation device 1 having a memory 2 and a programmingdevice interface 3. Inter alia, the so-called object model 4 and afunction interface 5 for accessing the object model 4 are stored in thememory 2.

The object model 4 of the automation device 1 is accessed by 5 anexternal programming device 6, via the programming device interface 3and the function interface 5. The programming device interface 3 allowsthe establishment of a communication connection 7 between programmingdevice 6 and automation device 1, and acts as an intermediary betweenprogramming device 6 and function interface 5. The programming device 6includes a counterpart (not shown) for converting data which is receivedfrom the automation device 1, wherein said counterpart corresponds tothe function interface 5.

If data of the object model 4 is to be read, for example, by theprogramming device 6, a corresponding request arrives at the functioninterface 5 from the programming device 6 via the programming deviceinterface 3, e.g. “get DB 1” (read data module 1). The functioninterface 5 includes means (not shown) for interpreting this request insuch a way that, for example, it is possible to access that area of theobject model 4 which represents the data module having the number 1 inthe memory 2. The corresponding memory area is made available by thefunction interface 5 for transmission to the programming device 6 viathe programming device interface 3, and is transmitted to theprogramming device 6 at a suitable time.

The same applies correspondingly when loading e.g. a function modulefrom the programming device 6 into the object model 4 of the automationdevice, e.g. “put FB 10” Write function module 10). The functioninterface 5 allows the access to that area of the object model 4 whichrepresents the relevant function module in the memory 2. The datareceived from the programming device 6 is written into this memory area.

An automation device 1 having memory 2, object model 4, functioninterface 5 and programming device interface 3 is known from the priorart.

The automation device 1 also includes a standard interface 8, therebyallowing the connection of any terminal 11, e.g. a standard computer 11such as are normally used for office applications today, over acorresponding communication connection 9, possibly involvingintermediate switching of communication connections via the so-calledinternet 10.

The so-called protocol which is used for communicating betweenautomation device 1 and programming device 6 is usually a proprietaryprotocol, which often is specified by the manufacturer of the relevantautomation device 1 specifically for said device. In this case, theproprietary nature is essentially derived from the specificfunctionality of the function interface 5, which includes means forconverting requests such as “get DB 1” or “put FB 10” directly intoaccesses to the object model 4.

In order to allow an exchange of data between the automation device 1and a standard terminal 11, the proprietary protocol which is used forcommunicating between automation device 1 and programming device 6 isnot used. Instead, general conventional protocols such as FTP or NFS,for example, are used. Software for handling data transfers inaccordance with FTP or NFS on the terminal 11 is available in a widevariety of forms, and therefore the user of the terminal 11 can choosefrom the existing products according to the local requirements orlimiting conditions (operating system, memory space).

When software for handling data transfers in accordance with FTP or NFSis executed, either a so-called server 12 or a so-called client 12, oreven a server 12 and a client 12, is set up on the terminal 11.

A complementary functionality 13 is provided on the automation deviceside in order to allow the communication with the client 12 and/or theserver 12 of the terminal 11. The description continues by describingthe case in which a client 12 is present on the terminal 11 side and acorresponding server 13 is present on the automation device side forhandling the standard protocol which is selected in each case.

Communication requests in accordance with the standard protocol are sentfrom the client 12 to the server 13, e.g. “get DB 1” to transfer thedata module having the number 1 from the object model 4 of theautomation device 1 to the terminal, or “put FB 10” to transfer afunction module from the terminal 11 to the object model 4 at theposition in the memory 2 which represents the function module having thenumber 10. The server 13 passes the communication request to a converter14, which converts the communication request in accordance with thestandard protocol into a communication request which can be handled bythe function interface 5 of the automation device 1. The functioninterface 5 allows the access to the object model 4 of the automationdevice, and hence the read or write access to the memory 2 in accordancewith the original communication request, to take place.

FIG. 2 shows a schematic hierarchical illustration of an object model 4of an automation device 1. The columns 41, 42, 43, 44 representhierarchy levels within the object model 4. A highest hierarchy level 41comprises the complete object model 4 of a specific automation device 1,designated as “S7-300” here. In an underlying hierarchy level 42, theobject model is divided into binary data 421, description data 422 anddesign data 423. In a next lower hierarchy level 43, the binary data421, for example, is divided into organization modules (OBs) in binaryformat 431, data modules (DBs) in binary format 432, function modules(FBs) in binary format 433, inputs (E) in binary format 434, outputs (A)in binary format 435, and a process image of the inputs (PE) in binaryformat 436, etc. The description data 422 is correspondingly dividedinto organization modules (OBs) having a description 437, data modules(DBs) having a description 438, etc. Finally, the design data 423 isdivided into system data modules (SDBs) 439, log files (LOGs) 440, etc.In a lowest hierarchy level 44, the totality of e.g. the organizationmodules 431, 437 finally comprises the actual individual organizationmodules (OB0 . . . OBn) 441, 442, 443, 444. The totality of the datamodules 432, 438 correspondingly comprises the individual data modules(DB0 . . . DBn) 445, 446, 447, 448 in this lowest hierarchy level 44.

On the basis of this hierarchical structuring of the object model 4, itis possible—as when using known file managers of conventional operatingsystems—to access not only individual organization modules 441-444 ordata modules 445-448, but also the totality of e.g. all organizationmodules 431, 437 or data modules 432, 438. Accordingly, the completedata resources of the object model 4 can be transferred in binary format421 or together with explanatory description 422 by means of a singleaccess. Finally, even the object model 4 itself can be selected, andtherefore the complete object model can be transferred by means of asingle access.

This is possible because the individual elements 441 to 448 of theobject model 4, and likewise their grouped combinations 431 to 438, canbe managed in the same way as so-called directories (which are alsoreferred to as “folders”) and files are managed when using theaforementioned file managers. The object model 4 and its structure arepresented to the server 13 by the converter 14 in the hierarchicalformat described above.

This breaks through the “one-dimensional structure” which was routinelyused until now for the object model in automation devices, since similarcomponents are combined in groups and transferable in groups.

FIG. 3 shows a further illustration of the object model 4 in a formatwhich corresponds to the presentation of a directory structure byconventional file managers today. The reference signs correspond to thereference signs used in FIG. 2. The structure of the object model 4(“directory”, “dir”) of the relevant automation device 1 can be shown tothe user of the terminal 11 initially by means of the communication andtransfer commands of the selected standard protocol. The structure ofthe object model 4 is therefore represented graphically on the screen ofthe terminal 11, in the manner shown by way of example in FIG. 3. Inthis graphical representation, the user of the terminal 11 can selectindividual components to be transferred, e.g. all data modules in binaryformat 432 or the organization module having the number 1 includingdescription 443.

Similarly, messages such as e.g. status or error messages, etc., of theautomation device 1 are presented to the user in a convenient way. Allmessages of the same type, e.g. error messages, are combined into acorresponding group for this purpose. A plurality of groups, e.g. thegroup of all error messages, the group of all status messages, etc., arecombined into a separate group called “System message” if they relate toe.g. the automation device 1 itself, and into a further separate groupcalled “User message” if they relate to e.g. the user program which isexecuted by the automation device 1. This structure is representedgraphically at the screen of the terminal in the manner shown by way ofexample in FIG. 4.

The user on the terminal 11 side can quickly move through the resultinghierarchical structure to the desired type and category of message,and/or select individual messages or groups of messages to betransferred, e.g. for documentation purposes.

The invention can therefore be summarized as follows:

A method for accessing the data of an automation device 1 and anautomation device 1 suitable for the execution thereof are specified, inwhich an access to the data takes place via a remote terminal 11 inaccordance with a standard protocol, wherein the automation device 1 hasa client 13 and/or server 13 for handling communication requests inaccordance with the standard protocol, and a converter 14 for convertinga communication request into a format which can be processed by afunction interface 5 which is an internal functionality of theautomation device 1 for direct access to its data.

1.-14. (cancelled)
 15. A method for accessing data of an automationdevice having a memory and a function interface, wherein the functioninterface is stored in the memory and is used for accessing an objectmodel stored in the memory, the method comprising: forwarding acommunication request from a client or a server to a converter, whereinthe communication request relates to the object model; and convertingthe communication request by the converter into a format which can beprocessed by the function interface.
 16. The method as claimed in claim15, wherein the converter also converts a communication request from thefunction interface into a format which can be processed by the client orthe server and forwards the converted communication request to theclient or the server.
 17. The method as claimed in claim 15, wherein theclient or server is part of the automation device, is communicativelyconnected to a standard interface of the automation device, andprocesses communication requests which are received or sent via thestandard interface in accordance with a standard protocol.
 18. Themethod as claimed in claim 15, wherein the object model and itsstructure are presented to the client or server in a hierarchical formatby the converter.
 19. The method as claimed in claim 15, wherein theclient is an FTP client and/or the server is an FTP server.
 20. Themethod as claimed in claim 15, wherein the client is an NFS clientand/or the server is an NFS server.
 21. The method as claimed in claim15, wherein the client is an NNTP client and/or the server is an NNTPserver.
 22. The method as claimed in claim 15, comprising: calling up astructure of the object model in the form of its image, wherein thestructure comprises individual components of the object model; selectingindividual components or sets of components with reference to the imageof the structure of the object model; and accessing to the individualcomponents or sets of components, wherein data corresponding in thememory to the selected components is written or read via the functioninterface.
 23. The method as claimed in claim 22, wherein similarcomponents of the object model are combined in groups and aretransferable in groups.
 24. The method as claimed in claim 23, whereinthe structure of the object model is represented as a so-called treehaving a so-called root and at least one so-called branch and at leastone so-called leaf, wherein each leaf corresponds to a component of theobject model, and wherein each branch corresponds to a groupedcombination of similar components other branches.
 25. An automationdevice, comprising: a memory; a function interface, wherein the functioninterface is stored in the memory and is used for accessing an objectmodel which is stored in the memory; a converter; and a data processingsystem, wherein the data processing system forwards a communicationrequest to access the object model to the converter, and wherein theconverter is used for converting the communication request into a formatwhich can be processed by the function interface, and for forwarding theconverted communication request to the function interface.
 26. Theautomation device as claimed in claim 25, comprising a client and aserver.
 27. The automation device as claimed in claim 25, wherein thedata processing system is a client.
 28. The automation device as claimedin claim 25, wherein the data processing system is a server.
 29. Theautomation device as claimed in claim 25, comprising a standardinterface, wherein the client or server is communicatively connected tothe standard interface, and is used for processing communicationrequests which are received or sent via the standard interface inaccordance with a standard protocol.
 30. The automation device asclaimed in claim 25, wherein the converter is also used for converting acommunication request from the function interface into a format whichcan be processed by the client or the server, and for forwarding theconverted communication request to the client or the server.
 31. Theautomation device as claimed in claim 25, wherein the client is an FTPclient and/or the server is an FTP server.
 32. The automation device asclaimed in claim 25, wherein the client is an NFS client and/or theserver is an NFS server.
 33. The automation device as claimed in claim25, wherein the client is an NNTP client and/or the server is an NNTPserver.